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Abstract 

Dynamic  inheritance,  originating  in  the  Self  programming  language,  is  the 
ability  of  an  object  to  change  the  code  that  it  inherits  at  run  time.  This 
ability  is  useful  for  modeling  objects  that  behave  in  different  ways  at  dif¬ 
ferent  points  in  the  object’s  lifecycle.  Unstructured  dynamic  inheritance, 
however,  allows  arbitrary  changes  to  the  interface  of  the  object,  and  thus  is 
incompatible  with  statically  typechecked  languages  such  as  C++,  C#  and 
Java. 

This  paper  provides  a  more  structured  facility  for  dynamic  inheritance, 
where  a  type  system  tracks  the  changes  in  an  object’s  interface  that  oc¬ 
cur  as  the  inheritance  hierarchy  is  changed.  We  define  a  formal  model  of 
a  language  and  type  system  with  dynamic  inheritance,  and  prove  that  the 
type  system  is  sound  in  that  it  prevents  run-time  type  errors.  The  type 
system  tracks  the  linearity  of  objects  and  methods  in  order  to  ensure  that 
objects  whose  interfaces  change  are  not  aliased. 


|  socket  <  —  ()|  ”a  new  empty  object ” 
socket  AddSlots :  (| bind  =  (<  code  >  ... 

socket  AddSlots:  (| port  <  —Nil |)  ” adding  a  new  data  slot ” 

socket  AddSlots:  (| listen  =  (<  code  >  ... 
socket  AddSlots:  ( \accept  =  (<  code  >  ... 
socket  AddSlots:  (| read  =  (<  code  >)|) 
socket  AddSlots:  {{write  =  (|  :  data...  <  code  >)|) 
socket  AddSlots:  {{close  =  (<  code  >)|) 

)l))l))l) 

Figure  1:  TCP  socket  example  illustrating  the  expressiveness  of  Self  and  the  challenges  the  type  system  has 
to  deal  with 

1.  Introduction 

Objects,  by  their  nature,  often  have  different  behavior  in  different  stages  of  their  lifecycle.  However,  in  classical  object- 
oriented  languages  the  type  of  an  object  and  the  messages  it  understands  are  fixed  at  compile  time  and  cannot  be  changed 
at  run  time.  Self  [15]  is  a  prototype-based  object-oriented  language  that  allows  programmers  to  dynamically  change  the 
inheritance  hierarchy  and  the  set  of  methods  that  each  object  understands.  Thus  Self  objects  can  have  different  behavior 
at  different  moments.  This  model  is  appealing  for  implementing  a  large  variety  of  software  systems.  Several  interesting 
properties  of  the  language  are: 

•  There  are  no  classes  in  Self.  Instead,  a  prototype  mechanism  is  used  for  object  creation.  A  new  object  is  created  by 
cloning  (copying)  another  object  that  serves  as  its  prototype. 

•  There  is  no  distinction  between  state  and  behavior.  The  methods  and  fields  of  an  object  are  unified  into  slots.  A  slot 
with  a  function  can  be  used  to  model  a  method  and  a  slot  with  data  can  be  used  to  model  a  field.  Consequently,  there 
is  no  distinction  between  accessing  a  field  and  sending  a  message.  Every  object  is  simply  represented  by  a  list  of  slots. 

•  There  are  one  or  more  delegation  slots  that  refer  to  objects  from  which  behavior  is  inherited.  This  mechanism  allows 
objects  to  share  behavior  or  state.  The  object  can  change  the  objects  to  which  it  delegates  at  any  point  in  program 
execution.  Section  2  describes  a  number  of  situations  where  the  expressiveness  of  dynamic  inheritance  is  beneficial. 

•  Self  also  supports  adding  methods  dynamically  by  adding  a  new  slot.  A  method  body  (or  held)  can  be  changed  by 
changing  the  value  of  the  slot. 

Unfortunately,  the  additional  expressiveness  of  Self  comes  at  a  cost:  A  programmer  might  experience  “message  not 
understood”  errors  at  runtime.  Figure  1  demonstrates  how  a  Berkeley  TCP  socket  might  be  implemented  in  Self.  By  adding 
e.g.  the  port  held  only  after  bind  was  called  we  can  ensure  that  clients  cannot  read  uninitialized  values  from  the  object.  The 
same  applies  to  calling  methods  in  the  wrong  order:  since  the  body  of  bind  adds  the  listen  method,  clients  cannot  call  listen 
until  after  bind  has  been  called. 

However,  changing  delegation  and  adding  methods  at  run  time  to  objects  can  be  the  source  of  bugs  if  they  are  not  controlled. 
The  Self  compiler  has  no  way  of  statically  detecting  whether  the  port  is  dehned  on  a  socket  object  at  a  particular  point  in 
the  program.  Instead,  an  access  to  a  non-existing  slot  will  cause  a  “message  not  understood”  error  at  run  time.  It  is  easier 
to  identify  the  cause  of  this  error  than  it  would  be  if  the  method  call  succeeded  but  corrupted  the  socket’s  data  structures 
(as  might  happen  without  the  user  of  dynamic  method  addition),  but  nevertheless  it  would  be  nice  to  avoid  both  errors  using 
static  checking.  As  we  will  see  later,  aliasing  in  particular  makes  it  very  hard  for  the  programmer  to  manually  make  sure 
that  such  errors  cannot  occur.  As  a  result,  the  potential  benefits  of  dynamic  inheritance  and  method  change  at  run  time  are 
underutilized. 

The  contribution  of  this  paper  is  a  type  system  that  statically  ensures  that  all  accesses  to  object  slots  will  succeed  at 
runtime,  even  in  the  presence  of  dynamic  inheritance  and  method  changes.  We  formally  define  a  new  language,  Ego,  which 
is  similar  to  Self  but  restricts  Self’s  flexibility  somewhat.  In  particular  we  control  dynamic  changes  to  aliased  objects.  We 
designed  Ego  in  such  a  way  that  a  static  type  checker  can  guarantee  that  a  well  typed  program  will  lack  of  “message  not 
understood”  errors  at  run  time.  The  type  safety  proof  for  Ego  directly  implies  this  property. 

The  type  system  of  Ego  blends  the  features  of  several  previous  type  systems  in  order  to  achieve  soundness.  For  each  object 
it  keeps  track  of  all  methods  a  client  can  invoke.  The  type  system  distinguishes  between  linear  (non-aliased)  and  non-linear 
(aliased)  objects  [8].  It  statically  ensures  that  a  linear  variable  or  function  is  used  exactly  once,  while  allowing  aliasing  and 
multiple  uses  of  non-linear  objects  and  functions.  To  our  knowledge,  our  system  is  the  first  to  integrate  first-class  linear 
functions  in  an  object-oriented  environment. 

The  use  of  linearity  in  typing  objects  solves  crucial  aliasing  and  typing  issues.  Dynamic  changes  to  the  type  of  the  object 
(e.g.  by  adding  a  method)  are  only  permitted  to  linear  objects.  A  new  object  has  a  linear  type  when  it  is  created  and  the 
type  system  guarantees  its  linearity  during  the  program  unless  the  client  explicitly  makes  it  an  aliased  object  (on  which  fewer 
changes  are  allowed). 

Our  system  can  be  considered  a  foundation  for  research  into  more  flexible  typestate  systems  for  objects  [6,7].  As  a 
foundational  system,  it  may  not  be  as  succinct  or  easy  to  use  as  a  source-level  language,  but  instead  is  designed  to  further 
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understanding  into  the  core  mechanisms  of  typestate  and  to  explore  more  flexible  implementation  strategies  for  typestate, 
such  as  dynamic  changes  to  the  methods  and  superclass  of  an  object.  Incorporating  this  additional  flexibility  into  easy-to-use 
source-level  languages  is  an  interesting  area  of  future  work. 

The  remainder  of  this  paper  is  organized  as  follows.  Section  2  gives  an  intuitive  presentation  of  Ego  illustrated  with  a 
number  of  examples.  Section  3  introduces  the  core  language,  its  dynamic  semantics,  static  semantics,  and  a  brief  presentation 
of  the  type  safety  proof.  Section  4  summarizes  related  work,  and  the  last  section  concludes. 

2.  Overview  of  Ego 

This  section  gives  an  informal  introduction  to  our  language.  After  giving  a  brief  intuition  of  its  constructs,  we  show  how 
to  encode  some  common  object-oriented  programming  idioms.  We  then  discuss  how  Ego  tackles  the  important  problem  of 
aliasing.  That  forms  the  basis  for  a  detailed  description  of  how  methods  are  defined.  Finally  we  demonstrate  Ego’s  expressive 
power  with  a  number  of  examples.  Throughout  the  section  we  highlight  the  challenges  static  typechecking  has  to  deal  with. 

2.1  Language  Intuition 

A  program  in  Ego  is  an  expression.  An  expression  can  be  anything  from  a  simple  value  to  a  complex  object  manipulation. 
Some  kinds  of  expressions  can  contain  other  nested  expressions.  We  use  the  notion  of  lambda  abstractions  to  define  a  function 
and  bind  a  variable  in  its  body  expression.  Moreover,  we  introduce  a  number  of  primitives  for  object  manipulation  that  are 
inspired  by  the  work  on  Self  [15]. 

•  clone  allows  duplicating  an  object. 

•  delegate  sets  the  super  field  of  an  object,  thus  determining  from  whom  the  object  inherits. 

•  addMethod  is  used  for  adding  a  method  to  an  object  (or  changing  the  implementation  of  an  existing  method). 

•  changeJinearity  is  a  technical  primitive  used  for  dealing  with  aliasing,  as  we  shall  see  later. 

•  Finally,  in  typical  object-oriented  style,  e.m  invokes  a  method  on  an  object. 

The  first  four  primitives  yield  the  object  created  or  manipulated  to  be  used  in  the  surrounding  expression.  The  last  one  is 
used  for  method  calls  and  thus  yields  the  body  of  that  method. 

In  the  following  sections  we  will  develop  a  number  of  examples  that  show  these  primitives  in  action. 

2.2  Elementary  Programming  Idioms 

Ego  is  designed  as  a  core  language  for  expressing  dynamic  inheritance  and  method  addition.  We  can  define  a  number  of 
derived  forms  for  well-known  and  convenient  idioms  that  will  help  us  write  more  concise  programs.  That  will  also  help  us  in 
presenting  more  advanced  examples  in  the  remainder  of  the  section. 

This  section  focuses  on  the  notions  of  a  let  construct  and  instance  fields  for  objects.  We  will  also  discuss  how  to  create  new 
objects  and  how  to  use  them  like  traits  in  Self  (thus  in  a  class-like  manner). 

The  let  construct  is  well-known  from  languages  like  ML  [13].  It  typically  binds  a  variable  name  in  a  subsequent  expression 
(e.g.  let  x  =  5  in  x  +  1).  We  can  simulate  this  behavior  with  a  simple  lambda  expression  as  reflected  in  the  following  definition. 
It  also  allows  us  to  define  sequences  of  operations. 


let  x  :  t  =  ei  in  e2 


def 


(\x\T.e2)  ei 


uei  , 

ei;e2  =  let-~e\ine2 

Instance  fields  as  defined  in  object-oriented  languages  is  the  canonical  way  of  holding  values  in  an  object  over  which  that 
object  abstracts.  Methods  are  used  to  manipulate  the  fields  of  the  object.  Being  a  core  language,  Ego  does  not  incorporate 
any  form  of  information  hiding  (thus  everything  is  public).  It  also  does  not  support  fields  as  a  primitive.  Instead  we  can 
encode  fields  as  parameterless  methods.  Defining  a  field  would  look  like  the  following. 


ei ./  =  v  =  ei.addMethod(f,let  x  =  in  \self\r.x) 

This  will  also  work  for  reassigning  a  field  value.  In  this  case,  addMethod  will  just  redefine  the  method  body.  Note  that  ei 
has  to  be  an  object  and  we  use  a  let  binding  to  evaluate  e2  to  a  value  before  the  method  body  is  created.  Access  of  a  field 
then  becomes  invoking  a  parameterless  method  (with  e.f,  where  e  is  an  object  and  /  the  name  of  a  field). 

In  fact  we  can  use  the  above  derived  form  to  add  or  change  an  arbitrary  method  on  an  object:  If  /  is  itself  a  lambda 
expression  then  it  simply  defines  a  method  body  that  relies  on  additional  arguments.  (We  will  discuss  method  definitions  in 
detail  below.) 

How  do  we  get  an  object  in  the  first  place?  Ego  is  a  prototype-based  language  that  allows  us  to  clone  existing  objects. 
A  program  can  assume  the  variable  Object  bound  to  the  first  object  in  the  system.  Thus  creating  a  new  object,  adding  two 
methods,  and  invoking  the  first  one  can  be  realized  as  follows. 


2 


//  trait  for  s 

let  b  =  change  -linearity  (clone(Obj  ect)  .addM  ethod(service,  Xx:Nat.x  +  1))  in 
//  now  define  s  itself 

let  s  =  change Jinearity(clone{Obj ect) .delegate{b))  in 
II  and  finally  the  clients 

let  cl  =  clone(Object).addA4ethod(r,s)  in 
let  c2  =  clone(Obj ect). addM ethod(r,  s)  in 

II  invalid:  let  _  =  s.delegate(a)  in 
c2.r.service{5) 

Figure  2:  A  server  object  s  referenced  by  multiple  clients 


clone(Obj ect) . addMethod{m\ ,  ei ) . addMethod(m 2 ,  ei ) .mi 

Expressions  for  a  method  body  have  to  evaluate  to  a  lambda  abstraction  for  self.  When  a  method  is  executed,  the  receiver 
object  will  be  applied  to  this  outermost  lambda.  Objects  are  recursive  types,  thus  methods  can  refer  to  their  receiver  and  its 
(other)  methods  by  accessing  the  bound  variable  self. 

We  often  want  to  use  an  object  in  a  class-like  manner,  meaning  that  the  object  contains  instance  methods  to  be  used  by 
other  objects.  Such  an  object  is  called  a  trait  in  the  Self  literature  [15].  We  can  use  the  let  construct  in  combination  with 
delegation  to  realize  traits  as  shown  below. 


let  Trait  =  clone(Object).addMethod(succ,  Xself:r.self.f  +  1)  in 
clone[Ob j ect). delegate(Tr ait). addM ethod(f,  Xself:r.5).succ 

The  result  of  this  expression  would  be  6.  Obviously,  an  arbitrary  number  of  objects  can  be  defined  that  inherit  their 
behavior  from  the  Trait  object  above  by  delegation  and  define  their  own  /  field.  Another  option  is  to  simply  clone  the  trait 
object,  which  would  result  in  simply  duplicating  all  of  the  methods  of  Trait  rather  than  sharing  them  through  delegation.  We 
will  present  an  example  of  this  more  prototype- oriented  approach  in  a  later  section. 

2.3  Dealing  with  Aliasing 

So  far  we  have  ignored  a  major  complication  of  our  system:  Aliasing.  An  aliased  object  is  (possibly)  referred  to  by  multiple 
names  (references)  in  a  program  as  opposed  to  linear  objects  that  have  only  one  name.  Aliased  objects  are  also  called 
“non-linear”,  and  linear  ones  are  sometimes  called  “non-aliased” . 

In  an  object-oriented  setting,  aliasing  is  almost  inevitable  because  of  the  state  held  in  instance  fields.  A  very  common 
notion  is  that  a  server  object  s  is  used  by  multiple  clients  c;  that  all  hold  a  reference  to  s  in  their  fields  d.r.  s  is  then  heavily 
aliased  as  in  the  following  definition. 

//  trait  for  s 

let  b  =  clone(Obj ect). addM ethod{service,  Xx:Nat.x  +  1)  in 

II  now  define  s  itself 

let  s  =  clone{Obj ect). delegate^)  in 

II  and  finally  the  clients 

let  cl  =  clone(Object) .addA4ethod(r,  Xself\rc..s)  in 
let  c2  =  clone(Object) .addA4ethod(r,  Xself\Tc..s)  in 


If  we  now  change  the  configuration  of  s  e.g.  by  changing  its  delegate  from  b  to  a  with  s.delegate{a),  obviously  all  clients 
are  affected.  In  particular,  it  is  hard  to  tell  whether  s  will  still  work  the  way  its  current  clients  expect  it  to. 

For  this  reason,  we  forbid  a  change  of  delegation  for  aliased  objects  as  well  as  adding  or  changing  methods  for  such  objects 
if  it  changes  the  method’s  signature.  We  allow  methods  to  be  modified  for  aliased  objects  as  long  as  the  new  method  has  the 
same  signature  as  the  old  method.  This  allows  us  to  model  field  updates,  for  example. 

Moreover,  we  forbid  delegation  to  a  linear  object  (because  that  would  be  just  like  a  second  explicit  reference  to  that  object). 
Instead,  we  introduce  the  changeJinearity  primitive  mentioned  earlier  to  explicitly  convert  a  linear  into  an  aliased  object 
that  can  then  be  a  delegee.  Note  that  there  is  no  way  of  turning  an  aliased  object  back  into  a  linear  one.  Figure  2  correctly 
encodes  the  situation  described  above  in  Ego. 

Intuitively,  these  restrictions  have  to  do  with  the  typing  of  objects.  Changing  a  method  signature  or  the  delegation  changes 
the  type  of  the  object.  That  means  that  the  aliases  to  that  expression  somehow  would  have  to  invisibly  change  their  types 
as  well,  which  would  be  difficult  or  impossible  for  a  static  type  system  to  track  in  the  general  case.  Conversely,  changing  a 
linear  object  affects  only  the  type  of  the  expression  at  hand,  which  is  what  a  static  type  checker  tracks  anyway. 
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let  lin  =  clone  ( Object ) 

let  oclone  ( Object )  .addMethod  (l,  \\sel  f:\rfself,  lin))  in 
/ /  lin  is  no  longer  available 
let  (o2,  Un2)  —  o.l  in 

//  instead  we  can  now  use  lin2 

//  o2  replaces  o,  but  does  not  contain  1  any  more 

Figure  3:  A  linear  method  consuming  a  variable  on  the  stack  and  its  linear  receiver 


On  the  typing  level  we  introduce  a  linearity  flag  for  objects  and  lambdas  that  we  write  as  “j”.  chang eJinearity  explicitly 
removes  this  flag  for  an  object,  thus  making  it  possibly  aliased.  Bodies  of  linear  lambda  abstractions  have  access  to  the 
linear  variables  defined  in  the  context  of  that  abstraction  (i.e.  on  the  stack).  The  type  system  guarantees  that  such  linear 
variables  are  used  only  once.  (We  say  they  are  “consumed”  on  usage.)  Figure  3  gives  an  example  assuming  pairs  written  as 
( x,y ).  Non-linear  lambda-abstractions,  on  the  other  hand,  can  only  access  the  non-linear  variables  in  the  context.  Non-linear 
variables  can  be  used  multiple  times. 

We  call  all  methods  linear  that  have  a  linear  lambda.  Linear  methods  are  consumed  upon  invocation,  i.e.  they  are  effectively 
removed  from  the  receiver  object.  This  guarantees  the  linearity  of  the  context  variables:  If  we  could  call  the  linear  method 
l  from  figure  3  twice,  then  we  would  gain  two  aliases  to  lin  “through  the  back  door”.  As  recursive  calls  to  the  same  linear 
method  would  have  the  same  harmful  effect,  we  have  to  remove  a  linear  method  from  its  object  before  that  method’s  body  is 
evaluated.  Thus  the  method  l  in  figure  3  is  not  only  no  longer  available  after  l  was  evaluated,  but  l  cannot  invoke  itself  on 
self  again  either. 

We  forbid  cloning  of  objects  with  linear  methods  for  the  same  reason:  That  would  result  into  pairs  of  linear  methods 
accessing  the  very  same  variable.  However,  the  object  can  be  linear  (because  it  is  completely  duplicated),  and  the  resulting 
clone  is  linear  in  any  case.  Thus  all  objects  are  linear  in  the  beginning  of  their  lifetime  and  can  be  converted  into  a  non-linear 
object  explicitly  using  chang  eJinearity  (but  not  back  into  a  linear  object). 

An  alternative  to  the  solution  of  consuming  linear  methods  upon  invocation  would  be  to  consume  the  receiver  as  a  whole. 
We  consider  this  a  bad  choice:  Only  one  method  could  be  ever  executed  on  a  linear  object. 

Independently  from  the  linearity  of  a  lambda  itself,  its  argument  can  be  linear  or  non-linear.  A  linear  lambda  argument 
requires  a  linear  object.  The  object  applied  to  such  a  lambda  is  no  longer  available  at  the  invocation  site  after  that  application 
(again,  we  say  it  is  “consumed”).  However,  the  lambda  abstraction  can  return  its  argument  to  the  caller  as  the  method  o.l  in 
figure  3  illustrates,  o  is  no  longer  available  after  the  last  line,  but  it  is  passed  back  into  o2. 

2.4  Method  Definition 

In  order  to  capture  the  dynamic  manipulations  of  objects  statically,  Ego  types  objects  with  a  recursive  record  type  [1,9] 
containing  an  explicit  list  of  all  the  methods  the  object  defines  together  with  a  field  for  its  delegate.  A  linear  object  containing 
an  integer  field  as  well  as  a  linear  method  that  takes  an  integer  argument  and  yields  an  integer  would  be  typed  as  follows. 
The  object  delegates  to  an  empty  object  like  Object. 


t. j  <  field  :  t  — >  int,  UnMeth  :  t  — o  int  — o  int,  super  :<» 

We  use  — o  for  typing  linear  lambda  abstractions  and  — >  for  non-linear  ones.  Every  method  body  definition  must  be  an 
explicit  lambda  abstraction  for  self  the  receiver  object.  The  type  of  self  essentially  lists  all  methods  expected  to  be  defined 
for  the  receiver  -  not  just  those  needed  in  the  body.  Additional  arguments  can  be  captured  with  nested  lambdas. 

The  requirement  that  self  must  be  typed  with  a  recursive  record  type  is  essentially  not  different  from  typing  an  object  with 
a  class  name  in  e.g.  Java:  Since  the  methods  in  a  Java  class  cannot  be  manipulated  the  class  name  can  be  used  as  a  (shorter) 
synonym  for  a  record  type  containing  all  methods  defined  for  that  class. 

In  fact,  our  system  is  much  more  flexible  in  that  different  methods  can  declare  different  receiver  object  types.  The 
programmer  can  make  explicit  what  he  expects  will  change  over  the  lifetime  of  the  object.  He  can  hereby  enforce  possible 
sequences  of  method  invocations  on  the  object,  i.e.  the  object’s  protocol.  The  receiver  object  type  for  a  method  then  reflects 
the  typestate  the  object  has  to  be  in  [4]  for  invocations  of  that  method.  Figure  4  gives  an  example  of  method  definitions  using 
typestate.  Note  that  we  give  typedefs  for  several  record  types  in  the  beginning  to  improve  readability.  They  are  not  part  of 
the  core  Ego  language. 

We  illustrate  the  business  logic  of  a  Web-based  phonebook.  Such  applications  are  characterized  by  two-phased  actions: 
First,  the  user  indicates  the  type  of  action  he  wants  the  system  to  perform  (e.g.  create  a  new  entry  with  prepareNew).  The 
phonebook  application  will  then  present  a  form  to  enter  the  new  contact  information.  The  user  can  now  complete  the  action 
by  sending  an  ok  message  (or  cancel,  which  we  omit). 

Our  phonebook  therefore  has  a  default  and  an  action  state.  We  see  that  objects  in  the  default  state  have  three  methods, 
while  those  in  action  have  four.  The  methods  applicable  to  the  respective  states  can  be  easily  identified  by  the  types  of  their 
self  variables.  The  triggers  to  switch  from  one  state  to  the  other  are  the  business  methods  and  ok,  respectively. 

The  type  system  ensures  that  a  method  can  only  be  called  on  a  receiver  that  matches  its  expected  receiver  type  exactly, 
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typedef  entry  =  t.  <  name  :  t^string,  number  :  t^>string,  super  :<>> 
typedef  default  =  t.  j  <  prepareN ew  :  traction,  makeEditable  :  t^entry^action, 
confirmDelete  :  t^entry^action,  super  :<» 
typedef  action  =  t.  j  <  prepareN  ew  :  de/auZt— >t,  makeEditable  :  default^entry^t, 
confirmDelete  :  default^>entry—>t,  ok  :  default— ode  fault,  super  :<» 

let  Entry  =  clone(Object). 
addMethod(name,  Xself '.entry . 
addMethod[phone,  Xsel  f  '.entry in 

let  W ebPhonebook  =  clone(Object). 
addMethod(prepareNew,  Xself  :  default, 
let  cur  Entry  =  clone(Entry)  in 

self.addMethod(ok,  jA self  :  default./*  save  new  entry  */)). 
addMethod{makeEditable,\self  :  default. 

Xcur Entry  :  entry 

self.addMethod(ok,  jA  self  :  default./*  save  edited  entry  */)). 
addMethod(confirmDelete,  Xself  :  default. 

Xcur  Entry  :  entry. 

sel  f  ,addMethod{ok,  jA  self  :  default./*  delete  selected  entry  */)) 


Figure  4:  Web  phonebook  business  logic 


after  the  method  itself  has  been  removed  in  the  case  of  linear  methods.1  Thus,  in  the  default  state,  the  business  methods  can 
be  called  because  they  expect  a  receiver  of  type  default,  but  the  ok  method  cannot  be  called  because  it  is  not  even  part  of 
the  default  state. 

In  the  action  state,  the  three  business  methods  are  still  part  of  the  type,  but  they  cannot  be  called  because  these  non-linear 
methods  expect  an  object  in  the  default  state  and  the  receiver  is  in  the  action  state,  which  has  the  additional  method  ok.  On 
the  other  hand,  the  ok  method  is  linear,  and  it  can  be  called  in  the  action  state  because  once  you  take  the  ok  method  out  of 
the  action  type,  you  get  the  default  type  which  is  what  the  ok  method  expects. 

Note  that  ok  behaves  differently  depending  on  the  action  that  is  to  be  performed.  Therefore  each  business  method  defines 
its  own  ok  method. 

The  exact  type  matching  in  our  system  is  essential  in  the  case  of  linear  objects  to  make  sure  that  changes  to  the  object 
are  legal  with  respect  its  complete  current  type.  In  particular,  when  changing  delegation  the  type  system  has  to  determine 
the  exact  new  record  type  of  the  object,  which  can  only  be  done  on  the  basis  of  the  exact  old  type  of  the  object  and  its  new 
delegate.  Otherwise,  the  object  could  define  a  method  with  a  name  also  used  in  the  new  delegate  but  with  a  different  return 
type.  If  that  method  were  not  listed  in  the  object  type  (which  could  happen  if  we  allowed  subtyping  for  linear  objects)  then 
the  system  would  expect  the  wrong  return  type  (the  one  defined  in  the  delegate  object)  from  a  later  call  to  that  method. 

The  restriction  of  exact  type  tracking  could  be  relaxed  for  aliased  objects.  Here,  subtyping  could  be  introduced  to  accept 
objects  with  more  methods  than  expected,  because  the  object  type  cannot  change  in  a  way  that  would  introduce  the  problem 
mentioned  above.  Even  though  subtyping  is  well  defined  for  record  types,  we  elide  this  extension  from  our  formal  core  system 
to  keep  it  as  simple  as  possible. 

2.5  Expressive  Power 

The  examples  we  have  seen  so  far  were  mostly  intended  to  illustrate  syntax  and  semantics  of  Ego.  This  section  will  present 
higher-level  examples  in  order  to  demonstrate  the  expressiveness  of  the  language.  In  fact,  one  was  already  given  in  the  previous 
section  (figure  4)  to  illustrate  the  application  of  Ego  to  typestates.  We  will  see  typestates  again  in  the  examples  that  follow. 
The  final  one  will  implement  the  TCP  socket  from  the  introduction  in  Ego. 

The  examples  rely  on  dynamic  inheritance  and  adding  new  methods  to  objects  over  time.  They  are  therefore  not  directly 
expressible  in  languages  with  static  inheritance  like  Java.  They  are  expressible  in  Self,  but  Self  would  not  be  able  to 
statically  guarantee  that  the  program  evaluation  will  succeed  at  runtime.  Our  system  does  guarantee  successful  evaluation  of 
the  presented  examples  by  virtue  of  the  type  safety  proof  presented  later. 

Throughout  the  examples  we  rely  on  the  intuition  of  the  reader  to  assume  the  semantics  of  certain  objects  to  which  we 
merely  refer  by  name.  It  would  exceed  the  limitations  of  this  paper  to  define  a  sufficiently  large  library  explicitly  on  which 
interesting  high-level  examples  can  rely. 

Consider  the  Ego  program  in  figure  5.  It  models  the  workflow  in  a  company  between  a  manager,  her  secretary,  and  her 
designated  worker.  We  first  implement  the  secretary  who  can  do  some  work.  We  also  define  a  prototype  worker  who,  no 
surprise,  can  also  do  some  work.  We  define  a  concrete  secretary  as  opposed  to  a  prototype  worker  for  purely  pedagogical 
reasons.  Both  could  be  prototypes.  Also  note  that  we  do  not  use  the  trait  idiom  known  from  Self  to  generate  a  worker 

1  Removing  the  method  from  the  type  is  necessary  to  ensure  that  linear  methods  cannot  recursively  call  themselves.  Recursive 
calls  would  break  the  invariant  that  no  linear  method  is  called  more  than  once. 
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typedef  init  =  t.\<sec  :  worker  — >  u.  <  doWork  :  secret  — >  unit  >, 
setWorker  :  ( t—setWorker )  —o 

u.  <  doWork  :  worker^unit,  worker  Sick  :  worker^secret,  super:  <>  >  — o  worker , 
super:  <>  > 

typedef  worker  =  t.\<sec  :  t  — >  u.  <  doWork  :  secret  — >  unit  >, 

myworker  :  secret  — >  u.  <  doWork  :  t  — >  unit,  workerSick  :  t  — >  secret  >, 
super:  <  doWork  :  t  — >  unit,  workerSick  :  t  — >  secret  » 
typedef  secret  —  t.\<sec  :  worker  — >  u.  <  doWork  :  secret  — >  unit  >, 

myworker  :t  — >  w.  <  doWork  :  worker  — >  unit,  worker  Sick  :  worker  —>t>, 
worker  Recover  :  (t— worker  Recover)  —o  worker,  super  :<  doWork  :  t^unit  » 

let  Secretary  =  change-linearity (clone(Obj ect) . 
addMethod(doWork,  Xself  '.secret. \task:r. . . .))  in 

let  Worker  Prototype  =  clone(Object). 
addMethod(doWork,  Xself  -.worker.  Xtask:r. . . .) 
addMethod(workerSick,  Xself  -.worker  .  self  .deleg  ate(self.  sec). 

addMethod(worker Recover,  \Xself ’.secret  .  self  .delegate(sel f  .myworker)))  in 

let  Manager  =  clone[Object). 
addMethod{sec,  Xself  :  secret. Secretary). 
addMethod{setWorker,  \Xself  :  init. 

|A  newworker:u  .  <  doWork  :  worker  — >  unit,  worker  Sick  :  worker  — >  secret  >  . 
self  ,addMethod{myworker, 

Xself -.secret  .  ( self,newworker )). 
delegate(newworker) ) . 

setWorker(changeJinearity(clone(Worker Prototype)))  . . . 


Figure  5:  Using  delegation  to  implement  workflows 


let  PowerSupply  =  clone(Object). 

addMethod(generatePower,  Xself  :t.  <  generatePower  :  t  — >  power 
let  On  =  change-linearity (clone(Obj ect) . 

addMethod(getPower,  Xself  :t.\<supply,  on,  of  f,  super  :<  getPower  »  . 
self  .supply. generatePower))  in 

let  Off  =  changeJinearity{clone{Object))  in 

let  Power  Switch  =  clone(Obj  ect) . 

addMethod(on,  Xself  :t.\<supply,  on,  off,  super  :<»  .sel  f  .delegate[On) . 
addMethod(off,  Xself  :t.\<supply,  on,  of  f,  super  :<  getPower  »  .self.delegate(Off)  in 

let  ps  =  clone(Power Switch) .  addMethod(supply , 

Xself:t.\< supply,  on,  of  f,  super  :<  getPower  »  . PowerSupply )  in 
ps.on.  getPower.  getPower.of  f .on.  getPower. of  f 


Figure  6:  A  kernel  power  network  using  composition  and  delegation 


“class”.  Instead  we  define  the  worker  prototype  as  an  object  to  be  cloned  to  create  instances.  We  feel  that  this  more  closely 
resembles  the  real  world  where  different  workers  are  different  autonomous  individuals. 

Finally  we  implement  the  manager  who  has  fields  for  her  secretary  and  her  worker.  By  default,  the  manager  forwards  all 
the  work  she  has  to  do  to  her  worker.  We  do  this  simply  by  delegation.  (That  forces  the  complicated  typing  of  self  in  the 
two  doWork  implementations.)  We  stress  that  this  exactly  models  the  situation  in  a  real  company,  where  work  is  delegated 
from  one  to  the  other  person.  Slightly  confusing  might  be  the  implication  that  our  manager  does  not  even  “see”  the  work 
items  she  delegates  to  her  subordinate.  But  maybe  this  is  not  too  unrealistic,  either. 

Now  imagine  the  worker  gets  sick.  We  would  invoke  the  workerSick  method  on  our  manager.  That  causes  the  manager  to 
dump  her  work  onto  her  secretary  from  now  on.  The  secretary  cannot  get  sick,  so  that’s  a  safe  guess.  But  also,  the  manager 
expects  her  worker  to  recover  eventually.  Thus  she  defines  an  additional  method  workerRecover  to  anticipate  this  event.  Note 
that  this  changes  the  manager’s  signature.  She  is  now  in  a  different  state,  the  “worker  sick”  state.  workerRecover  is  defined  to 
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typedef  open  =  t.\  <  port  :  t  — >  (t,  int),read  :  t  — >  (t,  r), 
write  :  t  — >  r  — o  t,  dose  :  t  —°  unit,  super  :<» 

let  Socket  =  clone(Object). 
addMethod(bind,  \Xself  :  t. j  <>  .self.(. . .). 
addMethod(port,  \Xself  :  open.(self,prt )). 

addMethod (listen,  jA self  :  t.\  <  port  :  open  — *  ( t ,  int )  >  .self.(. . .). 
addMethod{accept,  jA  self  :  t.\  <  port  :  open  — >  (t,  int)  >  .self.(. . .) 
addMethodfread,  Xself  :  open.(self,  result)). 
addMethodfwrite,  Xself  :  open.\Xdata\T. . . . ;  self). 
addMethod(close,  \Xself\open. . . . ;  unit)))) 


Figure  7:  A  TCP  socket  object  in  Ego 


be  linear  and  thus  will  be  consumed  on  invocation.  The  method  will  also  redelegate  to  the  now  recovered  worker,  effectively 
transferring  the  manager  back  to  her  original  state.  As  a  final  remark  concerning  states  we  point  out  that  the  manager  is  in 
a  sort  of  initialization  state  before  setWorker  is  called.  Only  then  can  she  do  (or  rather,  delegate)  work. 

Next  we  implement  a  kernel  power  network  in  figure  6.  It  consists  of  a  power  supply,  an  on-off-switch  and  a  client  that 
requests  power.  In  this  example  we  use  delegation  to  model  the  different  states  of  the  power  switch  (on  and  off).  Obviously, 
only  the  On  object  has  a  getPower  method  that  forwards  the  power  request  to  the  supply  configured  for  that  object.  Thus 
our  client  first  has  to  connect  the  switch  to  the  supply  by  adding  the  supply  field.  Then  it  can  switch  on,  get  power  for  a 
while,  switch  off,  and  on  again  to  get  more  power. 

The  On  and  Off  objects  that  implement  the  two  controller  states  can  be  aliased  by  an  arbitrary  number  of  switches  that  all 
delegate  to  one  of  these  two  objects.  The  power  supply  is  unique  to  each  switch  (both  being  physical  devices)  and  therefore 
represented  as  an  instance  field  to  the  switch.  Without  that  field  defined,  the  switch  is  not  functional  as  the  signatures  for 
the  on  and  off  methods  do  not  match.  It  can  redirect  to  a  different  source  later,  though. 

The  power  network  example  uses  an  implementation  strategy  that  is  quite  the  opposite  to  the  workflow  example  above. 
In  the  power  network,  we  use  delegation  to  express  states  (on  and  off)  and  explicit  forwarding  (similar  to  composition  in 
object-oriented  programming)  to  transfer  the  power  from  the  supply  to  the  consumer.  In  the  workflow  example,  on  the  other 
hand,  we  added  and  removed  methods  to  change  the  state  of  the  manager  object.  We  used  delegation  to  (implicitly)  forward 
calls  from  one  object  to  the  other. 

Finally,  we  look  into  the  TCP  socket  example  from  the  introduction  section  again.  Figure  7  gives  an  implementation  in 
Ego.  We  do  not  use  delegation  at  all  but  rather  manipulate  the  object  with  each  method  call.  The  implementation  relies  on 
linear  methods  to  enforce  that  bind,  listen,  and  accept  are  called  exactly  once.  Each  of  these  generates  the  following  method; 
therefore  a  client  must  follow  the  prescribed  call  sequence. 

We  show  as  an  example  how  bind  also  generates  a  field  that  contains  the  port  on  which  the  socket  is  going  to  listen  in 
order  to  demonstrate  that  a  real  socket  implementation  is  a  full-blown  data  structure.  Derived  fields,  as  the  port  here,  can 
be  added  to  the  object  when  they  are  available  in  Ego,  effectively  preventing  reads  from  not  yet  defined  fields. 

The  call  to  accept  will  generate  read,  write,  and  close  methods.  The  first  two  can  now  be  called  an  arbitrary  number  of 
times.  They  require  a  linear  self  and  return  it  unchanged  upon  completion  of  the  call,  close  also  requires  a  linear  self  but 
does  not  give  it  back,  effectively  making  the  object  inaccessible.  Lending  [2]  or  borrowing  [4]  for  the  methods  returning  self 
would  make  this  explicit  return  unnecessary.  We  elide  this  possible  extension  to  Ego  for  simplicity. 

2.6  Summary 

In  the  preceding  sections  we  gave  an  informal  introduction  to  Ego.  We  have  seen  in  detail  how  programs  can  be  implemented 
in  the  language.  We  discussed  its  handling  of  aliasing  as  well  as  the  notion  of  typestates  which  it  naturally  supports  through 
its  method  definitions.  Finally  we  could  express  a  number  of  relevant  examples  in  Ego.  We  saw  that  delegation  and  dynamic 
method  changes  are  somewhat  substitutable,  effectively  allowing  different  programming  styles. 

The  examples  were  complex  enough  to  imagine  that  an  ad-hoc  Self  programmer  can  introduce  bugs  that  result  in  runtime 
errors.  That  motivates  the  need  for  static  typechecking  for  such  programs  in  order  to  make  sure  that  all  object  manipulations 
and  method  invocations  will  succeed.  Throughout  this  section  we  described  the  restrictions  Ego  imposes  on  the  programmer 
to  control  Self’s  “power  of  simplicity”.  We  have  seen  that  they  are  loose  enough  to  implement  interesting  programs  in 
Ego,  and  although  the  current  type  system  is  somewhat  complex  we  believe  this  can  be  simplified  considerably  in  a  practical 
system.  It  is  the  main  result  of  this  paper  that  these  restrictions  are  also  strong  enough  to  ensure  Ego’s  type  safety.  This 
will  be  formalized  in  the  next  section. 

3.  Formal  Model 

We  now  introduce  the  core  Ego  language  to  formalize  the  intuitions  given  above.  This  section  contains  the  full  dynamic 
semantics,  the  full  static  semantics,  and  a  summarized  type  safety  proof  of  Ego.  The  full  type  safety  proof  is  available  in  [3]. 

3.1  Syntax 
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Figure  8  presents  the  syntax  of  our  model.  We  do  not  include  base  types,  control  flow  structures,  exceptions,  and  subtyping 
into  the  model  as  they  are  well-known  from  the  literature.  We  omit  multiple  inheritance  and  polymorphism  as  these  are 
orthogonal  to  the  typing  issues  at  hand.  Note  that  an  overbar  is  used  to  represent  a  sequence. 

Each  program  is  an  expression.  An  expression  is  a  variable  (x) ,  a  value  ( v) ,  a  clone  of  an  object  (clone) ,  a  method  invocation 
(.m),  an  object  delegation  change  (delegate),  the  addition  of  a  new  method  to  an  object  or  the  change  of  a  method  body 
(addMethod),  a  function  application  (f  a)  and  a  change  of  the  type  linearity  of  an  object  (change .linearity).  A  method 
(M)  is  defined  as  a  pair:  the  name  of  the  method  (m)  and  an  expression  that  reduces  to  a  method  body.  A  method  body 
definition  is  a  lambda  expression  with  a  linearity  type  for  the  function.  We  will  enforce  that  the  outermost  lambda  types  the 
receiver  object.  Our  store  (S)  is  a  set  of  pairs:  the  location  of  the  object  and  the  object  descriptor  (Odescr).  An  object 
descriptor  is  a  pair:  the  location  of  the  super  object,  and  a  sequence  of  methods  defined  for  this  object.  There  are  four  kinds 
of  types:  for  variables  (t),  for  non-linear  functions  (— >),  for  linear  functions  (— o)  and  finally  for  objects  (t.R).  The  object 
type  is  a  recursive  type  where  t  is  bound  to  R.  The  record  type  (R)  is  a  list  of  the  types  of  the  methods  (B)  defined  for  the 
object  and  the  type  of  the  super  object  (super).  The  type  of  a  linear  object  is  presented  by  ;.  We  use  [;]  to  represent  that 
the  object  might  be  linear  or  non-linear.  Optional  syntax  is  enclosed  in  [  ]. 

Instance  variables  are  represented  by  parameterless  methods.  Locations  L,  l  are  not  part  of  the  source  code.  We  assume  to 
have  a  first  object  (Object)  defined  when  we  want  to  evaluate  a  program. 


(programs) 

p 

:=  e 

(expressions) 

e 

:=  x  |  v  |  e.m  \  e\.delegate(e2)  |  done(e) 
e.addMethod(M)  \  apply(ei,e2) 
changeJinearity(e) 

(method  sig) 

M  : 

:=  (m,e) 

(values) 

V 

:=  L  [i] Arc  :  r.e o 

(heap) 

S  : 

:=  (Object,  <  Object,  ()  >)  |  (L,  Odescr),  S 

(object  desc) 

Odescr 

■-  <l,(M1,...,Mn)> 

:=  t  |  t'  — >  t"  |  t.R  |  t'  — o  t" 

(types) 

T 

(records) 

R  : 

:=  [j]<>  |  [j]<  B,  super  :  r  > 

B  : 

:=  <>  |  <  m  :  r,  B  > 

(heap  location) 

L,  l 

(variable) 

X 

(type  variable) 

t 

(method  name) 

m 

Figure  8:  Syntax  of  the  language,  store,  types.  Angle  bracket  (<>)  inside  other  angle  brackets  are  deleted 
in  our  examples. 


3.2  Dynamic  Semantics 

The  dynamic  semantics  we  defined  for  Ego  is  a  standard  small  step  operational  semantics.  The  store  (S)  is  a  function 
from  locations  (L)  to  object  descriptors  (Odescr).  Figure  9  summarizes  the  rules  for  evaluating  expressions.  We  describe 
each  rule  in  turn. 

( R  —  Appl)  shows  how  a  method  is  applied  to  its  arguments.  We  write  [v/x]eo  for  the  result  of  replacing  x  by  v  in 
expressions  eo- 

( R  —  LInvk )  invokes  a  linear  method  on  an  object.  The  method  is  owned  by  the  receiver  and  is  linear.  As  the  type 
system  does  not  allow  another  call  to  that  linear  method  we  remove  it  from  the  store.  The  location  L  is  passed  as  an 
argument  to  the  method  because  self  is  not  a  free  variable  in  the  lambda  expression.  The  type  system  does  not  support 
this  in  order  to  not  have  aliasing  issues.  The  result  of  the  reduction  is  a  method  apply  with  L  as  an  argument  and  a  store 
without  the  method  m  in  it. 

(7?  —  NInvk)  invokes  a  non-linear  method.  The  result  of  the  reduction  is  the  same  as  the  one  above  except  that  the 
store  is  unchanged  now:  The  type  system  allows  the  client  to  invoke  a  non-linear  method  more  than  once  . 

( R  —  Clone)  creates  a  new  object  from  an  existing  one.  The  list  of  methods  and  the  address  of  the  super  object  are 
copied  from  the  cloned  object  to  the  newly  created  location. 

(R.  —  Deleg)  changes  the  reference  to  the  super  object  of  the  receiver  object.  The  result  of  the  reduction  is  the  mod¬ 
ified  location  of  the  receiver. 

( R  —  AddM)  adds  a  new  method  to  the  receiver  object.  The  result  returned  is  the  modified  location  of  the  receiver. 

( R  —  ChanMBd)  changes  the  body  of  method  (m)  of  the  receiver. 
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( R  —  ChanLin)  does  not  effect  the  memory.  It  changes  the  linearity  of  an  object  from  linear  to  non-linear.  The 
result  of  the  reduction  is  the  location  passed  as  argument  for  the  expression. 


- - -  R  —  Appl 

([i]A*  :  r  .eo)v,S  — >  [v/x\eo ,S 

S[L]  =  (l,  ((mi,  vi), ...,  (m,  v), ...))  v  is  linear  S'  =  S[L  — >  (l,  ((mi,  vi), ...))] 

L.m,S  — ►  vL),S' 

mbody(S[L\,  m)  =  v  v  is  nonlinear 

- - - - - 77 - -  R  -  NInvk 

L.m,  S  — >  vL,  b 

S[L\(l,M)  L'  (jL  domain(S)  S'  =  S[L’  ->•  (l,M)\ 


R  —  LInvk 


clone(L),  S  — >  L' ,  S' 

g[Ti]  =  (L,  M7)  S\L2]  =  (l2,  M77)  S'  =  S[L i  ->  (L2,W)\ 
Li. delegate(L2),  S  — >  Li,  S' 

S[L]  =  (l,  M)  m<£  dom(M )  S'  =  S[L  -*•  (l,  (M,  ( m ,  u)))] 
L.addMethod((m,  v)),  S  — >  L ,  S' 

£[-£-]  =  (l,  ((mi,  wO, ...,  (rthy),  ...(m  n  ?  Vn  ))) 
m  £  dom(M) 

S'  =  S[L  ->  ((mi,  -ui), ...,  (m,  v'), (m„,  v„))] 


R  —  Clone 


R  —  Deleg 


R  -  AddM 


L.addMethod(m,  v'),S  — >  L,  S' 


R  -  ChanMBd 


R  —  ChanLin 


change  Jinearity(L) ,  S  — >  L,  S 

Figure  9:  Evaluation  rules  for  expressions 


3.3  Static  Semantics 

Figure  11  presents  the  typing  rules  for  expressions.  Every  typing  rule  has  the  standard  form,  E;  A  b  e  :  r  =*>  liste  that 
contains  a  store  type  (E),  an  assumption  list  (A  or  A’),  an  expression  that  is  typed  (e),  the  type  of  the  expression  (r)and 
the  list  of  linear  objects  (liste)  that  are  used  to  type  the  expression. 

We  use  a  type  store  S  to  store  the  types  of  our  objects: 

E  ::=  Object  :  t.  <>  \  E;  l  :  r 

The  assumption  list  A  (or  A’)  contains  the  types  of  the  bound  variables  in  the  expression  e  that  is  typechecked.  An  assumption 
list,  A,  is  defined  as: 

A  ::=  •  I,  A,  x  :  r 

We  use  •  to  present  the  empty  assumption  list.  An  assumption  list  is  non-linear  if  each  assumption  x,:r.(  in  it  has  a  non-linear 
type  n.  Note  that  linear  variables  will  be  removed  from  the  assumption  list  upon  usage. 

The  type  expression  £.[j]<  mi  :  n, ...,  mk  :  Tk,  super  :  [j] <  mj  :  t{,  ...,  m'  :  rj  >>  is  a  type  t  with  the  property  that  when 

we  invoke  a  method  m;  for  1  <  i  <  k  or  a  method  m(  for  1  <  i  <  j  to  any  element  x  of  this  type,  like  x.mi,  the  result  has 
type  Tj  or  t[  with  t  substituted  for  t.R. 

Let  us  describe  each  rule  and  give  a  brief  justification  with  examples  for  selected  cases.  Note  that  the  word  location  is  used 
somewhat  ambiguous  because  sometimes  it  refers  to  the  label  of  a  location  and  sometimes  it  is  used  to  refer  to  an  object. 


M[m]  =  v 

mbody((l,M),m)  =v 
m  0  dom(M) 

mbody((l,  M),  m)  =  mbody(S[l],m) 

Figure  10:  Rules  for  lookup  of  methods  body. 
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However,  what  is  meant  is  always  obvious  from  the  context. 


(T  —  Loc)  A  location  is  well-typed  if  it  is  defined  in  E.  The  list  returned  is  empty  if  the  location  is  non-linear  or  L 
if  the  location  is  linear. 

(T  —  Method)  A  non-linear  method  is  well- typed  if  its  body  is  well- typed.  The  restriction  on  the  assumption  list  to 
be  non  linear  is  because  we  want  each  variable  needed  to  type  the  expression  to  be  non-linear  so  we  can  safely  call  the 
method  more  than  once.  There  is  no  restriction  on  the  arguments  of  the  methods  because  if  they  are  linear  there  is  no  way 
of  duplicating  them.  The  returned  list  is  empty  as  the  objects  used  here  are  all  non-linear. 

(T  —  LMethod )  A  linear  method,  too,  is  well-typed  if  its  body  is  well-typed.  However  in  this  rule,  there  is  no  re¬ 
striction  on  the  assumption  list.  Linear  variables  can  safely  be  used  in  a  linear  method  because  it  will  be  called  only  once 
during  the  program.  The  list  returned  is  the  one  returned  from  the  type  rule  applied  to  the  method  body. 

(T  —  Var )  The  type  of  a  variable  is  the  one  that  it  has  in  the  assumption  list.  The  returned  list  is  empty  as  there 
are  no  object  used  to  type  it.  The  assumption  list  has  only  the  record  to  type  the  variable.  The  type  system  does  not  require 
to  forget  information  in  the  assumption  list  during  the  typing  of  an  expression. 

(T  —  Kill)  This  rule  is  used  in  the  case  we  have  to  delete  a  record  from  the  assumption  list  in  order  to  typecheck  an 
expression.  We  need  it  in  typing  cases  like  jAja:  :  XX y  :  Y.x  where  y  can  be  non-linear.  As  long  as  it  is  not  used,  (T  —  Kill) 
can  remove  it  from  the  context  to  type  this  linear  method.  The  list  returned  is  the  same  as  the  expression  that  is  typed  with 
the  new  assumption  list. 

(T  —  Copy)  This  rule  makes  another  copy  of  a  non  linear  variable  in  the  assumption  list.  We  use  it  in  cases  like 
A*  :  Nat.x  +  x  or  Xx  :  X.(x.addMethod(m,  A y  :  Y.x))  where  x  is  non-linear.  The  type  system  has  to  explicitly  duplicate  x  in 
order  to  use  it  multiple  times. 

(T  —  Clone)  A  clone  expression  is  well-typed  if  e  (the  prototype  object)  is  well-typed  and  the  super  object  of  e  has 
a  non-linear  type  (which  is  true  automatically  by  virtue  of  (T  —  Deleg).  The  methods  defined  for  the  cloned  object  must  all 
be  non-linear  in  order  not  to  copy  references  to  linear  objects  through  the  back  door.  The  new  object  created  has  a  linear  type. 

(T  —  Invk)  A  .m  expression  is  well-typed  in  the  non-linear  case  if  e  (the  receiver)  and  m  are  well-typed,  both  non¬ 
linear  and  the  argument  type  of  m  is  the  same  as  the  type  of  the  object.  The  mtype  function  (see  Figure  12)  returns  the 
type  of  the  method  that  is  invoked.  The  type  system  does  not  allow  self  as  a  free  variable  for  aliasing  issues.  Instead  it 
requires  an  explicit  lambda  for  self.  The  following  example  will  help  clarifying  the  problem 

let  o  =  clone(Object). 
addMethod{m,  A_  :  unit. self). 
addMethod(m' ,  A_  :  unit. self  .m )  in 
(■ o.m).m '  /*method  m  is  invoked  twice*/ 

(T  —  LInvk)  The  difference  of  this  rule  from  the  one  above  is  that  e  (the  receiver)  is  linear  and  m  can  be  either  lin¬ 
ear  or  non-linear.  The  new  type  of  e  does  not  allow  the  client  to  call  m  again  if  m  is  linear.  We  do  that  by  deleting  the 
record  for  m  from  the  record  type  of  the  object.  This  prevents  aliasing  of  linear  objects  in  the  assumption  list  (the  stack). 
The  following  example  illustrates  the  idea 

let  obj  =  clone(Object).addMethod(m,\X:unit.self)  in 
let  obj 2  =  obj.mQ  in 

let  obj3  =  obj2.m()  /*we  have  two  references  to  obj*/ 

(T  —  AddM)  The  type-system  adds  new  methods  only  to  linear  objects  because  aliases  to  an  object  would  not  be 
aware  of  the  new  method.  The  assumption  list  used  to  type  the  expression  is  split  to  type  the  two  different  expressions,  ei 
and  e2,  in  order  to  track  the  linearity  of  the  objects.  The  list  returned  is  the  concatenation  of  the  lists  returned  from  the 
typing  rules  of  e  and  m. 

(T  —  LChanMBd)  This  rule  checks  if  the  object  is  linear  and  then  checks  if  the  new  method  body  is  well-typed. 
We  can  change  the  type  of  the  method  when  the  receiver  is  linear  just  like  we  can  add  new  methods. 

(T  —  ChanMBd)  This  rule  checks  if  the  object  is  non-linear  and  that  the  new  method  body  has  the  same  type  as 
the  existing  one.  We  do  that  for  the  same  typing  problem  we  can  have  in  the  T  —  AddM  or  T  —  Deleg. 

(' T  —  Deleg)  This  rule  permits  only  to  change  delegation  for  a  linear  objects  for  the  same  reason  the  type-system 
only  permits  new  methods  for  linear  objects.  The  rule  assures  also  to  delegate  to  a  non-linear  object  because  if  the  type 
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system  allows  the  client  to  delegate  to  linear  objects  then  we  effectively  have  more  than  one  reference  to  it. 

(T  —  ChanLin)  This  rule  changes  the  linearity  of  an  object  from  linear  to  non-linear.  The  super  object  is  non-linear 
anyway. 

(T  —  Appl )  This  rule  checks  if  the  first  expression  ei  has  a  function  type  and  that  the  second  expression  e2  has  the 
same  type  of  the  argument  of  ei. 

Figure  13  contains  the  rules  for  type-checking  the  store  S.  listi  is  a  list  of  all  linear  objects  used  to  type  the  location  S[Li ]. 
The  store  S  is  well-typed  if  every  location  in  the  store  is  well-typed.  A  location  L  is  well-typed  if  the  super  object  which 
it  inherit  is  well-typed  and  each  method’s  body  defined  for  that  location  is  well-typed.  listei  is  a  list  of  linear  objects  used 
during  the  typing  of  the  expression  e. 

3.4  Type  Safety 

In  this  section  we  describe  the  approach  taken  for  proving  type  safety  for  our  system. 

As  a  program  executes,  the  number  of  locations  in  the  store  can  expand  as  clone  operations  are  performed,  and  the  types 
of  locations  can  change  as  a  result  of  method  addition  or  delegation  changes.  We  formalize  the  way  the  store  type  can  change 
as  a  store  extension  operation  S'  >;  E.  This  judgment  means  that  E'  differs  from  S  because  of  l  in  one  of  two  cases  : 

1.  S'  may  have  an  additional  l  in  its  domain 

dom( S')  =  dom( S)  U  {1}  Ml'  £  dom(E).E(Z')  =  E'(Z') 

E'  >i  E 

2.  I  was  linear  in  E  but  is  non-linear  in  E' 

dom{ S')  =  dom(E)  VZ'  €  (dom(E)  -  Z}.E(Z')  =  E'(Z') 

S'  >*  E 

The  first  case  of  S'  and  S  is  introduced  by  the  clone  typing  rule  and  the  second  case  is  introduced  by  the  addMethod, 
delegate  or  changedinearity  typing  rules.  This  lemma  is  used  for  the  proof  of  T-AddM,  T-Deleg  and  T-Appl. 

1.  (Preservation)If  E;  •  b  e  :  r  =>■  liste  and  E;  •  b  S  :  E  =>■  lists  and  there  are  no  duplicates  in  liste,  lists  and 
e,S—>  e' ,  S'  then  for  some  S'  >i  E  we  have  E';  •  b  e!  :  r  =>■  liste  and  E';  •  b  S'  :  E7  lists'  and  there  are  no 
duplicates  in  listei ,  lists'  ■ 

2.  (Progress)  If  E;  •  b  e  :  r  =>■  liste  and  E;  ■  b  S  :  E  =>■  lists  then  either 

(i)  e,  S  — >  e! ,  S'  for  some  S'  and  e',  or 

(ii)  e  is  a  value  v 


Preservation..  Preservation  ensures  that  the  type  of  an  expression  is  preserved  during  its  evaluation.  For  the  proof  of 
preservation,  we  need  two  properties  about  the  substitution  operation  as  it  occurs  in  the  case  of  function  application  and  two 
lemmas. 

Theorem  1  (Properties  of  Typing) 

(i)  (Weakening)  If  E;  A,  A'  b  e’  :  t'  =>■  liste t  and  t  is  nonlinear  then  E;  A,  x  :  t,  A'  b  e!  :  t'  =>■  liste' ■ 

(ii)  (Substitution)If  E;  A,  x  :  r,  A!  b  e!  :  t'  ==>  liste'  and  E;  •  b  e  :  r  =>■  liste  then  E;  A ,  A'  b  {e/x}e'  :  t'  ==r  liste,liste' 
Proof:  Property  (i)  follows  directly  by  the  T-Kill  rule. 

Property  (ii)  follows  by  a  rule  induction  on  the  given  derivation  of  E;  A,  x  :  r,  A!  b  e'  :  t'  =*•  liste' ■  Since  typing  and 
substitution  are  both  compositional  over  the  structure  of  the  term,  the  only  interesting  cases  are  where  e'  is  x  or  [j]  Am.eo  - 

Case  .-(Rule  T-Var).  with  e'  =  x.  Then  r'  =  r,  liste'  =  {}  and  { e/x}e '  =  {e/x}x  =  e.  But  our  assumption  is  E;  •  b  e  :  r  => 
liste  so  we  can  conclude  this  by  weakening  property. 

Case:  (Rule  T-[Non]Linear  Method),  with  e'  =[j] Aj/ :  r".e0. 

1.  x  7^  y  ;  {e/x}(([]\y  :  r".e o)  =[i]Az  :  t" .(eo{z/y}{e/x'\)  where  z  ^  FV(e’)  &  FV(e)  ^  BV(e’).  So  we  have  to  show 
E;A,  A'  b[j]A«  :  t" .{eo{z/y}{e/x})  :  t"  — >  t'  ==»  liste,liste0,  where  liste'  =  listeo  by  definition.  We  apply  for  two 
times  the  inductive  hypothesis  for  the  new  expression,  (eo {z/y){e/x}). 

2.  If  x  =  y  then  {e/x}e'  =  e' .  Then  E;  A,  A!  be':  t'  =$■  liste'  ■ 
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E  (L)  =  t.R 
E;  •  h  L  :  t.R  =>  [L\ 


T  —  Loc 


E;  A,  x  :  t'  b  eo  :  t"  =>■  {} 

E;  A  b  (A*  :  t' .eo)  :  t'  — >  t"  =>■  {} 


T  —  Method  (x  0  A,  nonlinear  A) 


E;  A,  x  :  t'  h  eo  :  r"  ==>  listeo 
E;  A  h  (jAa;  :  t' .eo)  :  r'  — o  r"  =>■  liste 


T  -  LMethod  (x  £  A) 


E;  a;  :  r  b  x  :  r  ==>■  {} 


T- Var 


E;  A  b  u  :  U  =>■  Zistu 
E;  A,  a;  :  A'  h  u  :  (7  ==>■ 


T  -  Kill 


E;  A,  x  :  X,  x  :  X  b  w  :  [7  ==>■  listu 
E;  A,  a;  :  X  b  m  :  U  =>■ 


T  —  Copy  (nonlinear  X) 


E;Ahe:t[j]  <  B ,  super  :  t' .  <  B' ,  super  :  t" .R"  >=>■  liste 
Mm  G  B.E;  A  h  M(m)  :  r'  -*•  r"  =►  {} 

E;  A  h  done(e)  :  t.j<  B, super  :  t'.  <  B',  super  :  t" .R"  »=$•  liste 

E;Ahe:t.j<  (...,  to  :  t'[— >  /  — °]r"),  super  :  t1  .R  >==> 
r'  =  t. j<  (...,  [to:t'— >t"/  ]  ),  super  :  t1  .R  > 


T  —  Clone 


S;  A  h  6. to  :  t”  =>■  liste 


T  -  LInvk 


S;  A  b  e  :  t.  <  B,  super  :  t! .R  >=£■  liste 
mtype(m,  t.  <  B ,  super  :  t' .R  >)  =  t'  — +  r" 
t'  =t.  <  B ,  super  :  t'.B  > 

S;  A  h  e.rn  :  t"  ==>  liste 


T  -  Invk 


E;  A'  h  e2  :  r  ==>■  listen 

m<£B 

E;  A  h  ei  :  i.j<  B ,  super  :  t'.B  >=>■  listei 
E;  A,  A'  h  ei.adcLM  ethod((m,  e2))  :  f.j<<  B,m  :  r  >,  super  :  t'.B  >==^  listei ,  liste 


T  -  AddM 


E;  A  h  ei  :  t.\«  ...,  to  :  r', ...  >,  super  :  t' .R  >=>■  listei 
E;  A'  h  e2  :  r  =>■  listen 
to  G  B 

E;  A,  A'  h  ei ,addMethod(m,  ei)  :  t.\«  ...,  to  :  r, ...  >,  super  :  f'.B  >=>■  listei ,  liste 


T  -  LChanMBd 


E;  A  h  ei  :  t.  «  ...,  to  :  r', ...  >,  super  :  t' .R  >=>  listei 

S;A'he2 

/  // 
r  =  r  — »  t 

to  G  B 

E;  A,  A'  h  ei ,addMethod(m,  ei)  :  t.\«  ...,  to  :  r', ...  >,  super  :  t'.B  >=J>  listei 


T  -  ChanMBd 


E;  A  h  ei  :  ti.j<  Bi,  super  :  t' .R\  >=^  listei 
E;  A'  h  e2  :  ti.  <  Bi ,  super  :  >==>■  liste2 

E;  A,  A'  h  ei.delegate(ei)  :  ti.j<  Bi,  super  :  (t2-  <  Bi,  super  :  t".i?2  >)[ti/ti]  >=>  listei,  liste 


T  —  Deleg 


S;  A  I-  e  :  t.j<  B,  super  :  t! .  <  B',  super  :  t" .R"  »=>  liste 
E;  A  h  changejinearity(e)  :  t.  <  B,  super  :  t' .  <  B' ,  super  :  t" -R"  >>=>  liste 


T  —  ChanLin 


E;  A  h  ei  :  r'[— *  /  ^>]r"  =>  listei  E;  A'  h  e2  :  r'  ==>  liste 
E;  A,  A'  I-  eie2  :  r"  ==>  listei ,  liste2 


T  -  Appl 


Figure  11:  Static  semantics  of  expressions.  {}  represents  the  empty  list. 
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m  €  B  B  <  ...,  m  :  r, ...  > 
mtype(m,t.{ j]  <  B,  super  :  t'.R  >)  =  r 

m  B 

mtype(m,t.[\ ]  <  B,  super  :  t'.R  >)  =  mtype(m,t’ .R) 


Figure  12:  Rules  for  lookup  methods  type  in  a  record  type. 


MLi  €  dom( E).E;  •  1.  S(Lt)  :  E (U)  =>  listi 
E;  •  h  S  :  S  =>■  concat{listi) 


T  —  Store 


E(7)  =  t'.R  V(m;,  e;).S;  ■  b  a  :  n  =4-  listei 
E;  •  b<  l,  ((mi,  ei), (mn,  en))  >:  t.[j]  <  n,  super  :  t' .R  >=4  concat(listei) 


T  —  Odescr 


Figure  13:  Static  semantic  of  Store 


Next,  we  define  two  lemmas  that  are  useful  in  ensuring  that  linear  methods  and  objects  remain  unaliased  as  the  program 
executes. 

Lemma  2 

if  E;  A  b  e  :  r  =>■  liste  and  S'  >;  E  and  l  ^  liste  then  E';AI-e:r  =>  liste 

This  lemma  is  used  to  proof  that  if  the  old  list  (listei,liste2,  lists)  of  linear  objects  has  no  duplicates  and  part  of  that 
list  (listei,  lists)  has  changed  (list^,  list's)  because  of  an  evaluation  rule  then  the  modified  list  (liste'i,liste2,  list’s)  llas  110 
duplicates.  This  is  because  if  there  are  no  duplicates  in  the  bigger  list  there  could  not  possibly  be  duplicates  in  the  smaller 
one. 

Proof:  The  proof  follows  by  induction  on  the  typing  rule  of  e,  E;  A  b  e  :  r  =*>  liste.  ■ 


Lemma  3 

For  any  rule,  e,  S  — »  e' ,  S' ,  where  E;  •  b  e  :  r  =>  liste,  E;  •  b  S  :  E  ==^  lists  and  no  duplicates  liste,  lists,  and  for  E'  >i  E  and 
S';  ■  b  e'  :  t  =>  liste>,  S';  •  b  S'  :  S'  lists'  and  no  duplicate  in  lists’ ,liste>  then  {lists1}  f){Uste'}  ^  {lists}U{liste}U{l}. 

Proof:  By  rule  induction  on  the  derivation  e,  S  — >  e! ,  S'  ■ 


Theorem  4  (Preservation) 

If  E;  ■  b  e  :  r  =4-  liste  and  E;  •  b  S  :  E  =>  lists  there  are  no  duplicates  in  liste,  lists  and  e,  S  — >  e! ,  S'  then  for  some  S'  >i  S 
and  memory  S'  we  have  E';  •  b  e'  :  r  =4  liste'  and  S';  •  b  S'  :  E'  =>  lists'  and  there  are  no  duplicates  in  liste' ,  lists'. 

Proof:  By  rule  induction  on  the  derivation  of  e,  S  — >  e! ,  S' . 


Case(Rule  T-Invk). 


e,S 
e.m,  S 


e,S—>  e',  S' 

E;  ■  b  e.m  :  r"  =4  liste 

E;  •  b  S  :  E  =t*  lists 

No  duplicate  liste,  lists 

E;  •  b  e  :  t.  <  B,  super  :  t' .R  >=  t'  =4  liste 

mtype(m,  t.  <  B,  super  :  t' .R  >)  =  r'  — >  t" 

S'  >;  E,  E';  •  b  e!  :  t.  <  B,  super  :  t! .R  >=t>  liste' 

S';  •  b  S'  :  E'  lists'  an<3  no  duplicates  in  liste>,  lists' 
S';  ■  b  e! .m  :  t"  =>  liste’ 


e' ,  S' 
e'.m,  S' 


Same  proof  for  the  T-LInvk  rule  except  the  method  invokated  is  not  deleted. 


Subderivation 
Assumption 
Assumption 
Assumption 
By  inversion 
By  inversion 
By  i.h. 
By  i.h. 
By  rule 
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Case. 


m.body(S[L\,m)  =  v  v  is  nonlinear 
L.m,  S  — >  vL,  S 


S;  •  h  L.m  :  r"  =>•  {} 

S;  ■  h  S  :  E  =>  lists 
No  duplicate  lists 

E;  •  b  L  :  t.  <  B,  super  :  t' .R  >=  t  =>■  {} 
E;  •  b  M(m)  :  r'  -*•  t"  ==>  {} 

S;  •  b  vL  :  r"  =>  {} 


Assumption 
Assumption 
Assumption 
By  inversion 
By  inversion  of  T-Odescr 
By  rule 


Case. 


S[L]  =  ...))  v  is  linear  S' =  S[L 

L.m,  S  — >  vL,S 7 


S;  •  b  L.m  :t"=>L 
E;  •  b  S  :  E  =£*  lists 
No  duplicate  lists,  L 

E;  •  b  L  :  t.\<  (...,  m  :  r),  super  :  t' .R  >=>■  L 

t'  =  t.\<  (...,  [m  :  t]),  super  :  t! .R  >  E;  ■  b  M(m )  :  r  ==>  listm 


(i,  ((mi,  vi), ...))] 


Assumption 
Assumption 
Assumption* 
By  inversion 
By  inversion  of  T-Odescr 


Supposing  that  nr  has  a  linear  type  otherwise  the  proof  will  be  similar  to  the  one  above. 

let  E'  =  E [L  — >  t. j<  (...),  super  :  t' .R  >] 

L  0  listv 

S';  ■  b  v  :  t'  —  or”  ==>  listv 

S';  •  b  L  :  t. j<  (...),  super  :  t' .R  >=  r'  ==>  L  /’  By  rule 
E7;  ■  b  vL  :  t"  =>  listv,  L 

Vm  £  (...). S';  •  b  M(m)  :  r  =>  listm  /’  By  Assumption*  and  lemma  2 
S';  ■  b  S'(L)  :  S'(L)  =>  listL  -  listm 
E7;  ■  b  :  E1  =>  Zists  —  listm 


By  assumption* 
By  lemma  2 

By  rule 

** 

By  rule  and  ** 


We  have  to  prove  that  E';  •  b  [L/this\v  :  {[t" /t\r)[t" .\\<  (...)[t" /t\,  super  :  t'.R  >  ./ 1 \  ==>■  L,  listm-  We  do  it  using  the 
Subsitution  property.  We  have  that  S';  this  :  t"  b  m  :  r[t” /t\  =$■  listm  and  E';  ■  b  L  :  t" . j<  B[t" /t\,  super  :  t' .R  >=>  L  and 
so  from  substitution  property  we  have  that  E';  ■  b  [. L/this\v  :  ([f”/t]r)[t”.j<  (...)\t" /t\,  super  :  t'.R  >  /t"\  L,  listm 

No  duplicate  lists  ~  listm,  L,listm  fly  Assumption* 


Case  (Rule  T-  Clone). 


e,S  ->  e! ,  S' 

clone(e),  S  — >  clone(e'),  S' 

e,  S'  — >  e! ,  S' 

E;  •  b  clone(e )  :  t.\<  B,  super  :  t! .  <  B' ,  super  :  t" .R"  »=3>  liste 
E;  •  b  S  :  E  =>  lists 
No  duplicate  liste,  lists 

E;  ■  b  e  :  t.[j]  <  B,  super  :  t' .  <  B' ,  super  :  t".R"  »=>  liste 
Vm  £  B. E;  ■  b  M(m)  :  t'  r"  =>•  {} 

S'  >i  E,  S';  -be':  f.[j]  <  B,  super  :  t! .  <  B’ ,  super  :  t" .R"  »=>  listei 
S';  ■  b  S'  :  E'  =>■ 

No  duplicate  listei ,  lists’ 

Vm  £  RE';  •  b  M(m)  :  r'  ->  r"  ==>  {} 

S';  ■  b  clone(e')  :  t.\<  B,  super  :  t! .  <  B' ,  super  :  t" .R"  »==>  liste / 


Subderivation 
Assumption 
Assumption 
Assumption 
By  inversion 
By  inversion 
By  i.lr. 
By  i.lr. 
By  i.h. 
By  lemma  2 
By  rule 


Case. 

S[L]  =  (Z,M)  L'  (jL  dom(S)  S'  =  S[L'  ->  ( l,M )] 
clone(L),  S  — >  L' ,  S' 
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E;  ■  b  clone(L)  :  t. j<  B ,  super  :  t'.  <  B',  super  :  t" .R"  >>=>■  [B] 
E;  ■  b  S  :  E  =£*  lists 
No  duplicate  [B],  fists 

E;  •  b  L  :  t.[j]  <  B,  super  :  t! .  <  S',  super  :  t" .R"  »=>  [L] 

Vm  G  B. E;  ■  b  M(m)  :  r'  -►  r"  =>  {} 

let  S'  =  E [L'  — >  t.j<  B,  super  :  t'.  <  B',  super  :  t" .R"  >>]  then 
S';  ■bib  t.j<  B,  super  :  t'.  <  B' ,  super  :  t"  .R"  >>=>■  L' 

Vf  G  dom( E).E(f)  =  E'(f) 

Vi  G  dom(S)  and  Vm  G  S(f)  then 
S';  ■  b  M(m)  :  r  =>  listm 
E';-  b  S'{L')  :  E'(B')  ==>  {} 

S';  ■  b  S'  :  E'  ==>■  fists 
No  duplicate  lists,  L' 


Assumption 
Assumption 
Assumption** 
By  inversion 
By  inversion 

By  rule 

By  definition  of  S'  >i  E 

By  lemma  2 
By  rule  and  lemma  2 
By  rule 

By  assumption**  &  L’  ^  E 


Case(Rule  T-AddM). 


_ ei,  S  — >  ej,  S' _ 

e\.addMethod((rn,e2)),S  — >  e'i.addA4ethod((m,  e2)) 


ei,  S  — >  ej,  S' 

E;  •  b  ei.addMethod((m,  e2))  :  t. j<<  B,  m  :  r  >,  super  :  t' .R  > 

IXStf .  lltStf ,2 

E;  ■  b  S  :  E  =£*  fists 

No  duplicate  listei ,  liste2 ,  lists 

E;  ■  b  ei  :  t. j<  B,  super  :  t' .R  >==>  listei 

E;  ■  b  e2  :  t  =£-  liste2 

S'  >;  E,  S';  •  b  e'x  :  t.j<  B,  super  :  t'.B  >=£■  list e, 

S';  •  b  S'  :  E'  ==>■  fists' 

No  duplicate  liste^,  lists' 
l  G  list(e'i),  lists' 


Subderivation 

Assumption 
Assumption 
Assumption 
By  inversion 
By  inversion 
By  i.h. 
By  i.h. 
By  i.h. 


No  duplicate  in  liste'i,liste2,lists'  because  if  liste2,  listei,  lists  has  no  duplicate  then  from  lemma  3  liste2 ,  liste^ ,  lists'  has 
no  duplicate. 

I  0  liste2 

E';  ■  b  e2  :  r  =>  liste2  By  lemma  2 

E';  ■  b  e'i.addA'Iethod((m,  e2))  :  t.j<<  B,m  :  r  >,  super  :  t1  .R  > 

=>■  list e/  ,  liste2  By  rule  &  Lemma  2 


_ e2,S^e'2,S’ _ 

ei.addMethod((m,  e2)),  S  — >  ei.addA4ethod((m,e2)) 

Symmetric  to  the  previous  case. 

S[B]  =  (f,  M)  S' =  S[L  ->  (f ,  (M,  (m, «)))] 
L.addMethod((m,  v)),  S  — >  B,  S1' 

E;  ■  b  L.addMethod((m,  v))  :  t. j<<  B,m  :  r  >,  super  :  t'.B  >==>  B,  fist„ 

E;  ■  b  S  :  E  ==£-  fists 
No  duplicate  B,  listv,  lists 
E;  •  b  L  :  t. j<  B,  super  :  t'.B  >=>■  B 
E;-bti:r  =>■  listv 

let  S'  =  E[B  — >  t.|<<  B,m  :  t  >,  super  :  t! .R  >] 
then  S';  •  b  B  :  t.j<<  B,  m  :  r.  >,  super  :  t'.R  >=>  L 
L,  listv  has  no  duplicate  — ■>  B  0  listv 
S';  ■  b  v  :  t  =$■  listv 
Vf  G  dom( E).E(f)  =  E '(f) 

Vf  G  {dom(S)  —  L}  and  Vm  G  S'(f)  then 
S';  ■  b  M(m)  :  r  =>■  fistm 
S';  ■  b  S'  :  E'  =>  lists,  listv 
No  duplicate  L,  lists,  listv 

The  cases  for  T-LChanMBd  and  T-ChanMBd  are  similar  to  T-Addm. 


Assumption 
Assumption 
Assumption* 
By  inversion 
By  inversion 

By  rule 

By  rule  &  lemma  2 
By  definition  of  E'  >l  E 

By  lemma  2 
By  rule 
By  Assumption* 
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Case(T-Deleg). 


_ ei,g->ej,5' _ 

ei. delegate^),  S  — >  e[.delegate(e 2),  5' 


ei,  S'  — >  e'i,  S' 

E;  •  b  ei. delegate^)  :  Zi.j<  Bi,  super  :  Z2 ■  <  B2,  super  :  >  [ti/^2]  >=4>  liste 

S;  ■  h  S  :  E  =>  lists 

No  duplicate  liste,  lists 

E;  ■  b  ei  :  ti.j<  Bi, super  :  t! .Ri  >=>  listei 

S;  •  b  e2  :  fa-  <  B2,  super  :  t" .R2  >=>■  listen 

E'  >;  E,  S';  •  b  e'i  :  Zi.j<  Bi,  super  :  t' .Ri  >=>  list e/ 

S';  ■  b  S'  :  S'  =>•  ZisZS' 

No  duplicate  liste^,  lists' 
l  £  liste  ,  lists' 


Subderivation 
Assumption 
Assumption 
Assumption 
By  inversion 
By  inversion 
By  i.h. 
By  i.h. 
By  i.h. 

By  definition  of  E'  >1  S 


No  duplicate  in  liste'i,liste2,  lists1  because  if  liste2, listei, lists  has  no  duplicate  then  from  lemma  3  liste2,liste'i,  lists'  has 
no  duplicate. 

I  liste2 

S';  ■  b  e2  :  <2-  <  B2,  super  :  t" .R2  >=>■  liste2  By  lemma  2 

E';-  b  e'i. delegate^)  :  ti.j<  Bi,  super  :  t2-R2  >==>■  list et  ,  list e2  By  rule 


Case. 

S[L1]  =  (l1,W)  S[L2]  =  {l2,M*)  S’  =  S[L!  ->  (L2,W)] 
L\.delegate(L2),S  — >  L\,S' 


E;  ■  b  Li.delegate(L2 )  :  Zi.j<  B 1,  super  :  t2-  <  B2,  super  :  t" .R2  >>==>  Li 
E;  ■  b  S  :  E  =£*  lists 
No  duplicate  Lj,  lists 
E;  •  b  Li  :  ti.j<  Bi,  super  :  t' .Ri  >==$•  L\ 

E;  •  b  L2  :  t2-  <  B2,  super  :  t" .R2  >=>  {} 

let  E'  =  E[Li  — >  fi.j<  Bi,  super  :  t2.  <  B2,  super  :  t" .R2  >>] 

then  S';  •  b  Li  :  ti.j<  Bi,  super  :  t2-R2  >==>  L\ 

S';  ■  b  Z/2  :  t2.  <  B2,  super  :  t" .R2  > — >  {} 

Ml  £  dom(E).E(Z)  =  E'(Z) 

Ml  £  {dom(S)  —  Li}  and  Mm  £  S(l)  then 
S';  ■  b  M(m )  :  r  ==>  listm 
S';  ■  b  S'  :  E'  ==>  lists 
No  duplicate  Li,  lists 


Assumption 
Assumption 
Assumption* 
By  inversion 
By  inversion 

By  rule 
By  lemma  2 
By  definition  of  E'  >l  E 

By  Assumption*  and  lemma  2 
By  rule 
By  assumption* 


Case(T-Appl). 


_ ei,  S  — »  e'i,  S' _ 

apply  (ei,  e2),  S  — »  apply  (ei,  e2),  5" 


ei,  5  — >  el,  S' 

Subderivation 

E;  ■  b  apply{e i,e2)  :  r"  ==£■  listei,liste2 

Assumption 

E;  ■  b  S  :  E  =£*  lists 

Assumption 

No  duplicate  listei ,  liste2 ,  lists 

Assumption 

E;  ■  b  ei  :  r'[— >  /  —  o]r"  =>■  listei 

By  inversion 

E;  •  b  e2  :  r"  =>■  liste2 

By  inversion 

S'  >,  E,  S';  •  b  ei  :  r'[->  /  -  o]r"  Z*sZe, 

By  i.h. 

S';  ■  b  S'  :  E'  =>  ZisZS/ 

By  i.h. 

No  duplicate  list^,  lists' 

By  i.h. 

No  duplicate  in  listei  ,liste2,  lists'  because  if  liste2,  listei,  lists  has 
no  duplicate. 

no  duplicate  then  from  lemma  3  liste2 ,  list ei  ,  lists'  has 
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I  £  liste > ,  lists'  — *  l  0  liste2 
E';  •  b  e2  :  t'  =>• 

S';  ■  b  apply(e'1,  e2)  :  t"  =>■  list ei  ,  liste2 


(*) 

By  lemma  2 
By  rule 


_ e2,S^e’2,S' _ 

apply(ei,  e2),  S  — >  apply (e\,e'2),  S' 

Symmetric  to  the  previous  case. 

Case. 


([i]Ax  :  T.eo)v,S  — >  [w/ajjeo,^ 

E;  •  b  ([i]A*  :  t' .eo)v  :  t"  ==>  listeo,listv 

E;  ■  b  S  :  E  =£-  lists 

No  duplicate  listeo,listv,  lists 

E;  ■  b  [j]A®  :  r'.eo  :  t'[— >  /  -  o]r"  ==b  listeo 

E;  •  b  v  :  t'  =>  listv 

E;  •  b  [w/a:]eo  :  t"  ==>  listeo,  listv 


Assumption 
Assumption 
Assumption* 
By  inversion 
By  inversion 
By  Substitution  Property 


Case(T-ChanLin ). 


e,  S'  — >  e',  S' 

change Jinearity(e) ,  S  — >  change Jinearity(e') ,  S' 


e,  S  — >  e',  S' 

E;  •  b  chang eJinearity(e)  •.  t.  <  B,  super  :  t' .  <  B' ,  super  :  t" .R"  >>=>  liste 
E;  •  b  S  :  E  lists 
No  duplicate  liste,  lists 

E;  •  b  e  :  t.j<  B,  super  :  t' .  <  B' ,  super  :  t" .R"  >>==>  liste 

S'  >;  E,  S';  -be':  t.|<  B,  super  :  t'.  <  B',  super  :  t".R"  »=>  liste> 

S';  ■  b  S'  :  E'  ==>  lists' 

No  duplicate  liste' ,  lists' 

S';  ■  b  changeJinearity(e')  :  t.  <  B,  super  :  t' .  <  B' ,  super  :  t" .R"  »=>  liste' 


Subderivation 
Assumption 
Assumption 
Assumption 
By  inversion 
By  i.h. 
By  i.li. 
By  i.h. 
By  rule 


Case. 

changeJinearity(L),  S  — >  L,  S 

E;  •  b  chang eJinearity(L)  :  t.  <  B,  super  :  t' .  <  B',  super  :  t" -R"  »=>  L 
E;  •  b  S  :  E  lists 
No  duplicate  L,  lists 

E;  ■  b  L  :  t.j<  B,  super  :  t! .  <  B',  super  :  t" .R"  >>=*»  L 
let  S'  =  E[L  — >  1. 1<  B,  super  :  t' .  <  B',  super  :  t" .R"  >>] 
then  S';  •  b  L  :  t.  <  B,  super  :  t' .  <  B',  super  :  t".R"  >>==>  {} 

VI  6  dom(E).E(l)  =  E'(l) 

VI  6  (dom(S)  —  L}  and  Vm  £  S(l)  then 
S';  ■  b  M(m)  :  r  ==>  listm 
S';  ■  b  S  :  S'  =>  lists 


Assumption 
Assumption 
Assumption* 
By  inversion 

By  rule 

By  definition  of  E'  >l  E 

By  Assumption*  and  lemma  2 
By  rule 


Progess..  This  asserts  that  the  computation  of  closed  well-typed  expressions  will  never  get  stuck.  The  critical  observation 
behind  the  proof  of  the  progress  theorem  is  that  a  value  of  function  type  will  indeed  be  a  function  and  a  value  of  object 
type  be  an  object.  We  state  these  critical  properties  as  an  inversion  lemmas,  because  they  are  not  immediately  syntactically 
obvious. 

Lemma  5  (Value  inversion) 

(i)  If  E;  •  b  v  :  t.R  =$■  listv  then  v  =  L. 
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(ii)  If  £;  •  .b  v  :  r'[— >  /  —  o]r"  =*>  listv  then  v  =  [/]A*  :  r'.eo. 

Proof:  We  distinguish  cases  on  v  value  and  then  apply  inversion  to  the  given  typing  judgment. 

Property  ( i ). 

Case:  V  =  L..  We  are  done  because  v  =  L. 

Case:  v  =  [/ ]Xx  :  r'.eo..  Then  we  would  have  £;  ■  b  [j]  Aas  :  r'.eo  :  t.R,  which  is  impossible  by  inspection  of  the  typing  rules. 
Property  (ii). 

Case:  V  =  L..  Then  we  would  have  £;  •  b  L  :  r'[— >  /  —  o]r'',  which  is  impossible  by  inspection  of  the  typing  rules. 

Case:  v  —  [/]Aa:  :  r'.eo..  We  are  done  because  v  =  []] Aar  :  r'.eo.  ■ 

Now  we  can  prove  the  progress  theorem. 

Theorem  6  (Progress) 

If  £;  ■  b  e  :  r  liste  and  £;  •  b  S  :  £  =>■  lists  then  either 

(i)  e  is  a  value  v,  or 

(ii)  e,  S  — >  e',  5'  for  some  S'  and  e'. 

Proof:  By  induction  on  the  derivation  of  the  typing  judgment,  analyzing  all  possible  cases. 

Case(T-Loc). 

£(/.)  =  t.R 
£;  ■  b  L  :  t.R  =>  [L\ 

Then  L  value. 

Case(  T-[Non ] Linear  Method ). 

£;  A,  x  :  t'  b  eo  :  r"  listeo 
£;  A  b  (jA*  :  r'.eo)  :  r'  —  or"  => 

Then  [j] Aa;  :  r'.eo  value. 

Case(T-Var). 

£;i:rbi:r  ==>  {} 

This  case  is  impossible  since  the  context  can  not  be  empty.  Same  for  T-Kill  and  T-Copy. 

Case(T-CIone). 

£;  ■  b  e  :  t.[j]  <  B,  super  :  t' .  <  B' ,  super  :  t" .R"  >>==>  liste 
Vm  €  B.£;  ■  b  M (m)  :  r'  — >  r" 

£;  •  b  clone(e)  :  t. j<  B ,  super  :  t'.  <  B' ,  super  :  t" .R"  »=>  liste 

Either  e,  S'  — »■  e',  S"  for  e'  and  5"  or  e  is  a  value  v 
e,  S  —>  e',  S'' 

clone(e),  S  — »  done(e'),  S1' 
e  is  a  value  v 
e  —  L 

clone(L),  S  — >  L',S" 


By  i.h. 
First  subcase 
By  rule 
Second  subcase 
By  value  inversion 
By  rule 


CY/.vef  T-[ L  JInvk). 


£;  A  b  e  :  t.  <  B,  super  :  t' .R  >=$•  liste 
mtype(m,  <  B,  super  :  t' .R  >)  =  r'  — >  r"  =  r 

£;  >1  b  e.m  :  r[t.  <  B,  super  :  t' .R  >  /t]  =>  liste 
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Either  e,  S  — >  e! ,  S'7  for  e'  and  S'  or  e  is  a  value  v  By  i.h. 

e,  S  — >  e' ,  S'  First  subcase 

e.m,  S  — >  e'.m,  S'  By  rule 

e  value  Second  subcase 

e  =  L  By  value  inversion 

L.m,  S  — *  [L/this]v,  S'  By  rule 


The  same  proof  for  T-LInvk 

Case(T-AdclM). 

E;  A' ,  this  :  t.[/ j]  <  B,  super  :  t' .R  >b  ei  :  t'[— >  /  —  o \r"  ==>  liste2 

m  tfL  B 

E;  A  b  ei  :  t. j<  B,  super  :  t! .R  >=>■  listei 

listen  . l%Ste2 

By  i.h. 
First  subcase 
By  rule 
Second  subcase 
By  i.h. 
First  subsubcase 
By  rule 
Second  subsubcase 
By  value  inversion 
By  value  inversion 
By  rule 


E;  A,  A'  b  e\.addMethod{{m,  e2))  :  t  «  B,  m  :  r'[— >  /  —  o ]r"  >,  super  :  t' .R  >==J> 

Either  ei,  S  — >  e'\,  S'  for  ei  and  S'  or  ei  is  a  value  v 
ei,S  — >  ei,  S' 

ei.addMethod((m,  e2)),  S  — >  e[.addMethod((m,  e2)) ,  S' 
ei  value 

Either  e2 ,  S  — >  e'2 ,  S'  for  e'2  and  S'  or  e2  is  a  value  v 
e2  ,S-+e'2,S' 

ei.addMethod((m,  e2)),  S  — >  ei .addMethod((m,e2)),  S' 
e2  is  a  value  v 
ei  =  L 

e2  =  [i]A*  :  r'.eo 

L.addMethod{{m,  u)),  S  — >  L,  S' 


The  proof  for  T-LChanMBd  and  T-ChanMBd  is  similar  to  the  proof  above. 

Case(T-Delegate). 

E;  A  h  ei  :  ti.j<  super  :  t' .R\  >=^  listei  S;  A'  h  e2  :  t2-R2  =>  liste2 
E;  A,  A'  b  ei.delegcite(e2)  :  ti-j<  B\,  super  :  t2-R2[ti/t2]  >==>  listei ,  liste2 

Either  ei,  S  — +  ei,  5'  for  ei  and  S'  or  ei  is  a  value  v 
ei,  S'  — >  ei,  S' 

e\.delegate{e2),S  — >  e[. delegate^),  S' 
ei  value 

Either  e2 ,  S  — >  ei ,  S'  for  e'2  or  e2  value 
e2,  S  — >  ei,  S' 

ei. delegate^) ,  S  — >  ei.delegate(e2),  S' 
e2  value 
ei  =  L 
e2  =  L 

L\.addM ethod{L2 ),  S  — >  L\,  S' 


By  i.h. 
First  subcase 
By  rule 
Second  subcase 
By  i.h. 
First  subsubcase 
By  rule 
Second  subsubcase 
By  value  inversion 
By  value  inversion 
By  rule 


Case(T-ChanLin ). 

E;  A  h  e  :  t. j<  B ,  super  :  t' .  <  B’ ,  super  :  t" .R"  >>==>  liste 
E;  A  b  change  linearity(e)  :  t.  <  B,  super  :  t' .  <  B' ,  super  :  t" .R"  >>=^ 

Either  e,  S  — >  e7,  S'  for  e'  and  S7  or  e  is  a  value  u 
e,  S  — >  e',  S' 

changeJinearity(e),  S  — >  change  Jinearity(e') ,  S' 
e  value 
e  —  L 

change  Jinearity(L) ,  S  — »■  L,  S 


By  i.h. 
First  subcase 
By  rule 
Second  subcase 
By  value  inversion 
By  rule 
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Case(T-Appl). 


E;  A  b  ei  :  t'[— »  /  —  o]r"  ==>  listei  E;  A'  h  e2  :  r'  ==>■  liste2 
E;  A,  A'  b  apply  (ei,  e2)  :  r"  =>■  listei ,  liste2 

Either  ei,  S'  — >  e'j,  S"  for  ei  and  S"  or  ei  is  a  value  v 
ei,  S'  — >  ei,  S' 

apply{ei,  e2),  S  — »  apply(e i,  e2),  S' 
ei  value 

Either  e2 ,  S  — »  ei ,  S'  for  e2  or  e2  value 
e2,  S  — >  ei,  S' 

apply(e  1,  e2),  S  — »  apply(e  1,  e'2),  S' 
e2  value 

ei  =  [j]Aa:  :  r'.eo 
e2  —  E 

([i]Ax  :  r'.e0)(u),S  — >  [u/a:]eo,S 


By  i.h. 
First  subcase 
By  rule 
Second  subcase 
By  i.h. 
First  subsubcase 
By  rule 
Second  subsubcase 
By  value  inversion 
By  value  inversion 
By  rule 


4.  Related  work 

This  section  summarizes  related  work  in  language  foundations,  aliasing,  and  state-based  method  dispatch.  Self  [15]  was 
the  first  prototype-based  language  and  also  defined  mechanisms  for  dynamic  modifications  of  object  definitions.  We  largely 
adopt  that  expressiveness  but  make  it  statically  checkable. 

Abadi  and  Cardelli  use  prototype-based  object  calculi  to  study  issues  of  subtyping,  quantification,  and  the  typing  of  the 
receiver  object  self.  Fisher  and  Mitchell  describe  a  delegation-based  object  calculus  with  subtyping  and  type  inference  [9]. 
Compared  to  these  systems,  our  work  focuses  on  the  orthogonal  issue  of  ensuring  that  dynamic  type  changes  to  a  linear  object 
are  safe. 

Our  work  builds  on  Philip  Wadler’s  linear  type  system  [16],  which  in  turn  builds  on  a  foundational  linear  logic  developed 
by  Girard  [11].  The  concept  of  linear  types  in  [16]  is  used  more  for  resources  that  should  not  be  duplicated.  Resources  like 
files  should  have  linear  type  in  order  to  not  accidentally  duplicate  or  discard  them.  In  contrast,  our  system  uses  linear  types 
to  allow  the  client  to  safely  change  the  type  of  an  object.  In  addition,  we  show  how  linear  first-class  functions  like  those 
presented  in  [16]  can  be  naturally  used  in  an  object-oriented  system. 

Predicate  classes  [5]  and  its  more  general  form,  predicate  dispatch  [8]  support  method  dispatch  based  on  predicates  over  the 
run-time  state  of  the  object.  When  a  message  is  sent  in  these  systems,  the  predicates  of  all  relevent  methods  are  evaluated, 
and  the  method  chosen  is  the  one  with  the  most  specific  predicate  that  evaluates  to  true.  Dynamic  inheritance  and  dynamic 
method  modification  is  a  complimentary  way  to  get  similar  behavior:  instead  of  dispatching  indirectly  based  on  the  state  of 
an  object,  the  state  is  encoded  through  the  dispatch  hierarchy.  These  mechanisms  are  probably  complimentary,  with  each 
appropriate  in  different  situations;  one  advantage  of  our  approach  is  that  it  can  change  the  type  of  an  object,  rather  than  just 
which  method  is  selected  at  run  time. 

Typestates  were  initially  introduced  by  [14]  for  procedural  programming  languages.  [6]  defines  a  resource-controlling  system 
for  such  languages  based  on  keys.  Keys  can  optionally  be  parameterized  with  typestates.  This  class  of  systems  is  formally 
modeled  in  [12]  as  refinement  types  that  layer  additional,  changing  resources  on  a  conventional  static  type  system.  All  these 
approaches  do  not  consider  inheritance  and  effectively  only  allow  linear  types.  Thus  they  are  unsuitable  for  object-oriented 
languages. 

The  State  design  pattern  in  [10]  allows  implementing  different  behavior  for  a  method  depending  on  the  main  object’s  state. 
However,  there  is  no  way  of  statically  restricting  the  available  methods  for  a  state.  [7]  defined  a  model  for  tracking  typestates 
in  object-oriented  languages.  In  particular,  they  address  the  issue  of  typestates  in  the  presence  of  subtyping.  In  our  work, 
objects  have  a  dynamically  changing  type  instead  of  a  changing  typestate  layered  on  top  of  a  fixed  type. 

5.  Conclusions 

Ego  offers  a  prototype-based  language  that  has  expressiveness,  simplicity  and  a  static  typechecker.  The  expressiveness 
follows  from  dynamic  inheritance,  adding  methods,  changing  method  bodies,  and  even  changing  method  types  dynamically. 
Its  simplicity  follows  from  the  lack  of  the  class  concept,  from  the  concept  of  cloning  instead  of  instantiation,  and  from  the 
unification  of  fields  and  methods. 

Ego  imposes  restrictions  on  the  programmer  in  order  to  control  Self’s  “power  of  simplicity”.  These  are  loose  enough  to 
allow  interesting  programs  using  Ego’s  dynamic  features.  But  these  restrictions  are  also  strong  enough  to  ensure  Ego’s  static 
type  safety.  Its  static  typechecker  provides  a  safer  and  more  efficient  paradigm  than  Self:  Ego  programs  will  only  contain 
valid  method  invocations. 

In  future  work,  we  plan  to  investigate  adding  more  advanced  object-oriented  language  features  to  the  system,  including 
multiple  inheritance,  parametric  polymorphism,  and  multiple  dispatch.  Allowing  subtyping  for  non-linear  objects  is  easy, 
but  more  research  will  have  to  be  devoted  to  finding  ways  of  supporting  subtyping  along  with  dynamic  inheritance.  Recent 
developments  in  typestate  systems  may  provide  a  path  forward  here  [7]. 
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